Some multimedia applications provide a user with the ability to create and edit media content. For example, the user might have multiple different files that contain multimedia content and the user may wish to produce, from the multiple files, one file that contains edited content. These multimedia applications typically enable the user to trim certain portions of the files and/or stitch the files together in some fashion. These types of applications may also allow the user to add effects and transitions to the edited content. An effect is something that can cause the content to be modified so that it is presented in a manner that is different from the originally recorded content. For example, causing color video to be presented as black and white video is an example of an effect. A transition constitutes some means for changing between different content, e.g. a wipe transition.
There are, however, shortcomings with many multimedia applications and systems that are available today. Specifically, many applications and systems force trimming to be done only at key frames or frames that are independently decodable.
As an example, consider FIG. 1 which shows two key frames (K) and a number of intermediate frames (I). Key frames are frames that can be decoded or decompressed without any dependence on other frames. Intermediate frames, on the other hand, depend on other frames for decoding because they contain only data that describes differences relative to the other frames. Assume now that during the course of editing multimedia content, the user desires to trim the content at an intermediate frame—designated as the “desired trim point” in FIG. 1. Many applications treat this problem in one of two ways. First, an application may allow trimming at this point, but will force decompression of the entire file. Second, the application may not allow trimming at the intermediate frame, but rather will force trimming to take place at the previous key frame—designated as the “forced trim point” in FIG. 1. Needless to say, neither of these solutions is desirable as, in the first case, content that is not necessarily needed for the user-desired processing is decompressed and recompressed thus adding to the processing complexity and overhead. In the second case, the user's editing wishes are not complied with and, in this particular example, will result in including content that the user does not wish to include.
Consider now that the user wishes to piece together portions of two different files. Many applications will allow files to be stitched together—but do so blindly and without any regard to or appreciation for the effects of stitching the files together. That is, typically in this scenario, the entire file of each portion to be stitched together is decompressed, blindly stitched together, and recompressed. One problem that can arise from this scenario, in addition to decompressing unneeded content, is that at the junction of the two file portions, bit rate conditions (such as maintaining a constant bit rate) for file streaming may be violated such that when the file is streamed, the viewer may see a glitch or some other manifestation of degraded quality. For users who wish to share their projects over a network by streaming the resultant output file to another user, this solution is undesirable.
With respect to the quality issue, decompressing the entirety of each file, operating upon portions of the decoded files, and then re-encoding the output file can be problematic for a couple of different reasons. First, by decoding the entirety of the files, portions that are not operated upon by the user are unnecessarily decoded. Second, re-encoding the entire output file, as noted above, is very expensive in terms of the resources and the time required for re-encoding. Additionally, and perhaps more importantly, each time that content is decoded and re-encoded, it resembles the original content less and less. This can and does lead to degraded quality.